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Abstract 
This document extends the Incident Object Description Exchange Format 


(IODEF) defined in RFC 5070 to exchange enriched cybersecurity 
information among security experts at organizations and facilitate 


their operations. It provides a well-defined pattern to consistently 
embed structured information, such as identifier- and XML-based 
information. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7203. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The number of incidents in cyber society is growing day by day. 
Incident information needs to be reported, exchanged, and shared 
among organizations in order to cope with the situation. IODEF is 
one of the tools already in use that enables such an exchange. 


To more efficiently run security operations, information exchanged 
between organizations needs to be machine readable.  IODEF provides a 
means to describe the incident information, but it often needs to 
include various non-structured types of incident-related data in 
order to convey more specific details about what is occurring. 
Further structure within IODEF increases the machine-readability of 
the document, thus providing a means for better automating certain 
security operations. 


Within the security community there exist various means for 
Specifying structured descriptions of cybersecurity information, such 
as [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS], 
[CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF]. In this 
context, cybersecurity information encompasses a broad range of 
structured data representation types that may be used to assess or 
report on the security posture of an asset or set of assets. Such 
structured descriptions facilitate a better understanding of an 
incident while enabling more streamlined automated security 
operations. Because of this, it would be beneficial to embed and 
convey these types of information inside IODEF documents. 


This document extends IODEF to embed and convey various types of 
structured information. Since IODEF defines a flexible and 
extensible format and supports a granular level of specificity, this 
document defines an extension to IODEF instead of defining a new 
report format. For clarity, and to eliminate duplication, only the 
additional structures necessary for describing the exchange of such 
structured information are provided. 


Terminology 


The terminology used in this document follows the terminology defined 
in RFC 5070 [RFC5070]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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Applicability 


To maintain awareness of the continually changing security threat 
landscape, organizations need to exchange cybersecurity information, 
which includes the following information: attack pattern, platform 
information, vulnerability and weakness, countermeasure instruction, 


computer event logs, and severity assessments.  IODEF provides a 
scheme to describe and exchange such information among interested 
parties. However, it does not define the detailed formats to specify 


such information. 


There already exist structured and detailed formats for describing 
these types of information that can be used in facilitating such an 
exchange. They include [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], 
[CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and 
[XCCDF]. By embedding them into the IODEF document, the document can 
convey more detailed context information to the receivers, and the 
document can be easily reused. 


The use of formats for structured information facilitates more 
advanced security operations on the receiver side. Since the 
information is machine readable, the data can be processed by 
computers, thus allowing better automation of security operations. 


For instance, an organization wishing to report a security incident 
wants to describe what vulnerability was exploited. In this case, 
the sender can simply use IODEF, where an XML-based [XML1.0] attack 
pattern record that follows the syntax and vocabulary defined by an 
industry specification is embedded, instead of describing everything 
in free-form text. The receiver can identify the needed details of 
the attack pattern by looking up some of the XML tags defined by the 
specification. The receiver can accumulate the attack pattern record 
in its database and could distribute it to the interested parties as 
needed, all without requiring human intervention. 


In another example, an administrator is investigating an incident and 
has detected a configuration problem that he wishes to share with a 
partner organization to prevent the same event from occurring at the 
partner organization. To confirm that the configuration was in fact 
vulnerable, he uses an internal repository to access configuration 
information that was gathered prior to the initial attack and that is 
Specific to a new vulnerability alert. He uses this information to 
automatically generate an XML-based software configuration 
description, embed it in an IODEF document, and send the resulting 
IODEF document to the partner organization. 
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4. Extension Definition 


This document extends IODEF to embed structured information by 
introducing new classes that can be embedded consistently inside an 
IODEF document as element contents of the AdditionalData and 
RecordItem classes [RFC5070]. 


4.1. IANA Table for Structured Cybersecurity Information 


This extension embeds structured cybersecurity information (SCI) 
defined by other specifications. The list of supported 
Specifications is managed by IANA, and this document defines the 
needed fields for the list's entry. 


Each entry for each specification has the namespace [XMLNames], 
Specification name, version, reference URI, and applicable classes. 
Arbitrary URIs that may help readers understand the specification 
could be embedded inside the Reference URI field, but it is 
recommended that a standard/informational URI describing the 
Specification be prepared and embedded here. 


The initial IANA table has only one entry, as follows: 


Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2 
Specification Name: Malware Metadata Exchange Format 
Version: 1.2 

Reference URI: «http://standards.ieee.org/develop 


/indconn/icsg/mmdef.html», 

«http://grouper.ieee.org/groups 

/malware/malwg/Schemal.2/» 
Applicable Classes: AttackPattern 


Note that the specification was developed by The Institute of 
Electrical and Electronics Engineers, Incorporated (IEEE), through 
the Industry Connections Security Group (ICSG) of its Standards 
Association. 


The table is managed by IANA, following the allocation policy 
Specified in Section 7. 


The SpecID attributes of extension classes (Section 4.5) must allow 
the values of the specifications' namespace fields, but 
implementations are otherwise not required to support all 
Specifications of the IANA table and may choose which specifications 
to support. However, at a minimum, the specification listed in the 
initial IANA table needs to be supported, as described in Section 5. 
If an implementation received data that it does not support, it may 
expand its functionality by looking up the IANA table or notify the 
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sender of its inability to parse the data. Note that the lookup 
could be done manually or automatically, but automatic download of 
data from IANA's website is not recommended, since it is not designed 
for mass retrieval of data by multiple devices. 


4.2. Extended Data Type: XMLDATA 


This extension inherits all of the data types defined in the IODEF 
data model. One data type is added: XMLDATA. Embedded XML data is 
represented by the XMLDATA data type. This type is defined as the 
extension to the iodef:ExtensionType [RFC5070], whose dtype attribute 
is set to "xml". 


4.3. Extending IODEF 


This document defines eight extension classes, namely AttackPattern, 
Platform, Vulnerability, Scoring, Weakness, EventReport, 
Verification, and Remediation. Figure 1 describes the relationships 
between the IODEF Incident class [RFC5070] and the newly defined 
classes. It is expressed in Unified Modeling Language (UML) syntax 
per RFC 5070 [RFC5070]. The UML representation is for illustrative 
purposes only; elements are specified in XML as defined in 

Section 5.2. 
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p--------------- t 
| Incident | 
+--------------- + 
ENUM purpose  |«»--------- [IncidentID] 
STRING [«»--(0..1)-[AlternativeID] 
ext-purpose |<>--{0..1}-[RelatedActivity] 
ENUM lang |<>--{0..1}-[DetectTime] 
ENUM |<>--{0..1}-[StartTime] 
restriction |<>--{0..1}-[EndTime] 
<>--------- [ReportTime] 


|<>--{0..*}-[Description] 

|<>--{1..*}- [Assessment] 

|<>--{0..*}-[Method] 

| |<>--{0..*}-[AdditionalData] 
| |<>--{0..*}-[AttackPattern] 
«»--(0..*)-[Vulnerability] 
<>--(0..*)-[Weakness] 
|«»--(1..*)- [Contact] 
|<>--{0..*}-[EventData] 

| |<>--{0..*}-[Flow] 
| 

| 

| 

| 


| |<>--{1..*}-[System] 
|<>--{0..*}-[AdditionalData] 
|<>--{0..*}-[Platform] 
|<>--{0..*}-[Expectation] 
|<>--{0..1}-[Record] 
|<>--{1..*}-[RecordData] 
|<>--{1..*}-[RecordItem] 
|<>--{0..*}-[EventReport] 


<>--{0..1}-[History] 
|<>--{0..*}-[AdditionalData] 

| |<>--{0..*}- [Verification] 
| |<>--{0..*}- [Remediation] 


Figure 1: Incident Class 
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4.4. Basic Structure of the Extension Classes 


Figure 2 shows the basic structure of the extension classes. Some of 
the extension classes have extra elements as defined in Section 4.5, 
but the basic structure is the same. 


4--------------------- * 

| New Class Name | 

4--------------------- * 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID | 

4--------------------- * 


Figure 2: Basic Structure 
Three attributes are defined as indicated below: 


SpecID: REQUIRED. ENUM. A specification's identifier that 
Specifies the format of structured information. The value should 
be chosen from the namespaces [XMLNames] listed in the IANA table 
(Section 4.1) or "private". The value "private" is prepared for 
conveying structured information based on a format that is not 
listed in the table. This is usually used for conveying data 
formatted according to an organization's private schema. When the 
value "private" is used, ext-SpecID element MUST be used. 


ext-SpecID: OPTIONAL. STRING. A specification's identifier that 
specifies the format of structured information. This is usually 
used to support a private schema that is not listed in the IANA 
table (Section 4.1). This attribute MUST be used only when the 
value of the SpecID element is "private." 


ContentID: OPTIONAL. STRING. An identifier of structured 
information. Depending on the extension classes, the content of 
the structured information differs. This attribute enables IODEF 
documents to convey the identifier of the structured information 
instead of conveying the information itself. 


Likewise, two elements are defined as indicated below: 


RawData: Zero or more. XMLDATA. An XML document of structured 
information. This is a complete document that is formatted 
according to the specification and its version identified by the 
SpecID/ext-SpecID. When this element is used, writers/senders 
MUST ensure that the namespace specified by SpecID/ext-SpecID and 
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the schema of the XML are consistent; if not, the namespace 
identified by SpecID SHOULD be preferred, and the inconsistency 
SHOULD be logged so a human can correct the problem. 


Reference: Zero or more of iodef:Reference [RFC5070]. A reference 
to structured information. This element allows an IODEF document 
to include a link to structured information instead of directly 
embedding it into a RawData element. 


Though ContentID is an optional attribute, and RawData and Reference 
are optional elements, one of them MUST be used to convey structured 
information. Note that, in order to avoid confusing the receiver, 
only one of them SHOULD be used. 


4.5. Defining Extension Classes 


This document defines eight extension classes, as described in the 
subsections that follow. 


4.5.1. AttackPattern 


An AttackPattern is an extension class to the 
Incident.Method.AdditionalData element with a dtype of "xml". It 
describes attack patterns of incidents or events. It is RECOMMENDED 
that the Method class [RFC5070] contain the extension elements 
whenever available. An AttackPattern class is structured as follows: 


4R--------------------- * 

| AttackPattern | 

4+--------------------- + 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID [<>--(0..*)-[ Reference ] 
| STRING ContentID |<>--(0..*)-[ Platform ] 
4R--------------------- * 


Figure 3: AttackPattern Class 


This class has the following attributes: 
SpecID: REQUIRED.  ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of attack pattern 
information. See Section 4.4. 
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Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of attack pattern 
information. See Section 4.4. 


Reference: Zero or more. A reference to attack pattern information. 
See Section 4.4. 


Platform: Zero or more. An identifier of the software platform 
involved in the specific attack pattern. See Section 4.5.2. 


4.5.2. Platform 


A Platform is an extension class that identifies a software platform. 
It is RECOMMENDED that the AttackPattern, Vulnerability, Weakness, 
and System [RFC5070] classes contain the extension elements whenever 
available. A Platform element is structured as follows: 


R--------------------- t 
| Platform | 
4+--------------------- + 
ENUM SpecID «»--(0..*)-[ RawData ] 
STRING ext-SpecID «»--(0..*)-[ Reference ] 
| STRING ContentID | 
4+—--------------------- + 


Figure 4: Platform Class 
This class has the following attributes: 
SpecID: REQUIRED. ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of platform 
information. See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of platform 
information. See Section 4.4. 


Reference: Zero or more. A reference to platform information. See 
Section 4.4. 
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4.5.3. Vulnerability 


A Vulnerability is an extension class to the 
Incident.Method.AdditionalData element with a dtype of "xml". The 
extension describes the vulnerabilities that are exposed or were 
exploited in incidents. It is RECOMMENDED that the Method class 
contain the extension elements whenever available. A Vulnerability 
element is structured as follows: 


4R--------------------- + 

| Vulnerability | 

4R--------------------- + 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID |<>--(0..*)-[ Platform ] 
| |<>--(0..*)-[ Scoring ] 
4R--------------------- + 


Figure 5: Vulnerability Class 
This class has the following attributes: 
SpecID: REQUIRED. ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of vulnerability 
information. See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of vulnerability 
information. See Section 4.4. 


Reference: Zero or more. A reference to vulnerability information. 
See Section 4.4. 


Platform: Zero or more. An identifier of the software platform 
affected by the vulnerability. See Section 4.5.2. 


Scoring: Zero or more. An indicator of the severity of the 
vulnerability. See Section 4.5.4. 


4.5.4. Scoring 


A Scoring is an extension class that describes the severity scores in 
terms of security. It is RECOMMENDED that the Vulnerability and 
Weakness classes contain the extension elements whenever available. 
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A Scoring class is structured as follows: 


4--------------------- + 

| Scoring | 

4--------------------- + 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID | 

4-----------2---------- + 


Figure 6: Scoring Class 
This class has the following attributes: 
SpecID: REQUIRED. ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of a score set. See 
Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of a score set. 
See Section 4.4. 


Reference: Zero or more. A reference to a score set. See 
Section 4.4. 


4.5.5. Weakness 


A Weakness is an extension class to the 

Incident .Method.AdditionalData element with a dtype of "xml". The 
extension describes the weakness types that are exposed or were 
exploited in incidents. It is RECOMMENDED that the Method class 
contain the extension elements whenever available. A Weakness 
element is structured as follows: 


4R-------------2-------- * 

| Weakness | 

4--------------------- + 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID |<>--(0..*)-[ Platform ] 
| |<>--(0..*)-[ Scoring ] 
4R-------------2-------- + 


Figure 7: Weakness Class 
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This class has the following attributes: 
SpecID: REQUIRED.  ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of weakness 
information. See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of weakness 
information. See Section 4.4. 
Reference: Zero or more. A reference to weakness information. See 


Section 4.4. 


Platform: Zero or more. An identifier of the software platform 
affected by the weakness. See Section 4.5.2. 


Scoring: Zero or more. An indicator of the severity of the 
weakness. See Section 4.5.4. 


4.5.6.  EventReport 


An EventReport is an extension class to the 

Incident .EventData.Record.RecordData.RecordItem element with a dtype 
of "xml". The extension embeds structured event reports. It is 
RECOMMENDED that the RecordItem class contain the extension elements 
whenever available. An EventReport element is structured as follows: 


4--------------------- * 

| EventReport 

4--------------------- * 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID | 

4--------------------- * 


Figure 8: EventReport Class 
This class has the following attributes: 
SpecID: REQUIRED.  ENUM. See Section 4.4. 


ext-SpecID: OPTIONAL. STRING. See Section 4.4. 
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ContentID: OPTIONAL. STRING. An identifier of an event report. 
See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of an event 
report. See Section 4.4. 
Reference: Zero or more. A reference to an event report. See 


Section 4.4. 


4.5.7. Verification 


A Verification is an extension class to the Incident.AdditionalData 
element with a dtype of "xml". The extension elements describe 
information on verifying security, e.g., a checklist, to cope with 
incidents. It is RECOMMENDED that the Incident class contain the 
extension elements whenever available. A Verification class is 
Structured as follows: 


4--------------------- * 

| Verification | 

4--------------------- * 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| STRING ContentID | 

4--------------------- * 


Figure 9: Verification Class 
This class has the following attributes: 
SpecID: REQUIRED.  ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of verification 
information. See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of verification 
information. See Section 4.4. 
Reference: Zero or more. A reference to verification information. 


See Section 4.4. 
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4.5.8. Remediation 


A Remediation is an extension class to the Incident.AdditionalData 
element with a dtype of "xml". The extension elements describe 
incident remediation information, including instructions. It is 
RECOMMENDED that the Incident class contain the extension elements 
whenever available. A Remediation class is structured as follows: 


4--------------------- * 

| Remediation | 

4--------------------- - 

| ENUM SpecID |<>--(0..*)-[ RawData ] 

| STRING ext-SpecID |<>--(0..*)-[ Reference ] 
| String ContentID | 

4--------------------- * 


Figure 10: Remediation Class 
This class has the following attributes: 
SpecID: REQUIRED. ENUM. See Section 4.4. 
ext-SpecID: OPTIONAL. STRING. See Section 4.4. 


ContentID: OPTIONAL. STRING. An identifier of remediation 
information. See Section 4.4. 


Likewise, this class has the following elements: 


RawData: Zero or more. XMLDATA. An XML document of remediation 
information. See Section 4.4. 
Reference: Zero or more. A reference to remediation information. 


See Section 4.4. 
5. Mandatory-to-Implement Features 


Implementations compliant with this document MUST be capable of 
sending and receiving the extended IODEF documents that contain XML 
documents conforming to the specification listed in the initial IANA 
table described in Section 4.1 without error. The extended IODEF 
document is an XML document that MUST be well-formed and MUST be 
valid according to schemata, including extension schemata, available 
to the validator and applicable to the XML document. Note that the 
receiver can look up the namespace in the IANA table to understand 
what specifications the embedded XML documents follow. 
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For the purpose of facilitating the understanding of mandatory-to- 
implement features, the following subsections provide an XML document 
conformant to this memo, and a corresponding schema. 


5.1. An Example XML Document 


An example IODEF document for checking an implementation's conformity 
with mandatory-to-implement features is provided here. The document 
carries Malware Metadata Exchange Format (MMDEF) metadata. Note that 
the metadata is generated by genMMDEF [MMDEF] with EICAR [EICAR] 
files. Due to the limit of 72 characters per line, some line breaks 
were added in this example. 


<?xml version="1.0" encoding-"UTF-8"?» 
<IODEF-Document version="1.00" lang="en" 
xmlns-"urn:ietf:params:xml:ns:iodef-1.0" 
xmlns:iodef-"urn:ietf:params:xml:ns:iodef-1.0" 
xmlns:sci-"urn:ietf:params:xml:ns:iodef-sci-1.0" 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance"» 
«Incident purpose="reporting"> 
«IncidentID name="sci.example.com">189493</IncidentID> 
<ReportTime>2013-06-18T23:19:24+00:00</ReportTime> 
«Description»a candidate security incident</Description> 
<Assessment> 
«Impact completion="failed" type="admin" /> 
</Assessment> 
<Method> 
<Description>A candidate attack event</Description> 
<AdditionalData dtype="xml"> 
<sci:AttackPattern SpecID= 
"urn:ietf:params:xml:ns:mile:mmdef:1.2"> 
<sci:RawData dtype="xml"> 
<malwareMetaData xmlns="http://xml/metadataSharing.xsd" 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation-"http://xml/metadataSharing.xsd 
file:metadataSharing.xsd" version="1.200000" id="10000"> 
<company>N/A</company> 
<author>MMDEF Generation Script</author> 
<comment>Test MMDEF v1.2 file generated using genMMDEF 
</comment> 
<timestamp>2013-03-23T15:12:50.726000</timestamp> 
<objects> 
«file id="6ce6f415d8475545be5ba114f208b0ff"> 
«md5»6ce6f415d8475545be5bal14f208b0ff«/md5» 
«shal»da39a3ee5e6b4b0d3255bfef95601890a£d80709«/shal» 
<sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464 
9b934ca495991b7852b855</sha256> 
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<sha512>cf83el357eefb8bdf1542850d66d8007d620e4050b 
5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff83 
18d2877eec2f63b931bd47417a81a538327af927 
da3e</sha512> 
<size>184</size> 
«filename»eicar com.zip«/filename» 
<MIMEType>application/zip</MIMEType> 
</file> 
«file id="44d88612fea8a8f36de82e1278abb02f"> 
<md5>44d88612fea8a8f36de82e1278abb02f</md5> 
<shal>3395856ce81f2b7382dee72602f798b642f14140</shal> 
<sha256>275a021bbfb6489%e54d471899f7db9d1663fc695ec 
2fe2a2c4538aabf651fd0f</sha256> 
<sha512>cc805d5fablfd71a4ab352a9c533e65fb2d5b88551 
8f4e565e68847223b8e6b85cb48f3afad842726d99 
239c9e36505c64b0dc92061d9e507d833277ada3 
36ab</sha512> 
<size>68</size> 
<crc32>1750191932</crc32> 
<filename>eicar.com</filename> 
<filenameWithinInstaller>eicar.com 
</filenameWithinInstaller> 
</file> 
</objects> 
<relationships> 
«relationship type="createdBy" id="1"> 
<source> 
<ref>file[tid="6ce6f415d8475545be5ba114f208b0ff"] 
</ref> 
</source> 
<target> 
<ref>file[@id="44d88612fea8a8f36de82e1278abb02f"] 
</ref> 
</target> 
<timestamp>2013-03-23T15:12:50.744000</timestamp> 
</relationship> 
</relationships> 
</malwareMetaData> 
</sci:RawData> 
«/sci:AttackPattern» 
«/AdditionalData» 
«/Method» 
«Contact role="creator" type-"organization"» 
<ContactName>sci.example.com</ContactName> 
<RegistryHandle registry="arin">sci.example-com 
</RegistryHandle> 
<Email>contact@csirt.example.com</Email> 
</Contact> 
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«EventData» 
«Flow» 
«System category="source"> 
«Node» 
«Address category="ipv4-addr">192.0.2.200</Address> 
«Counter type="event">57</Counter> 
«/Node» 
«/System» 
«System category-"target"» 
«Node» 
«Address category="ipv4-net">192.0.2.16/28</Address> 
«/Node» 
«Service ip protocol-"4"» 
<Port>80</Port> 
</Service> 
</System> 
</Flow> 
<Expectation action-"block-host" /> 
<Expectation action="other" /> 
</EventData> 
</Incident> 
</TODEF-Document> 


5.2. An XML Schema for the Extension 


An XML schema describing the elements defined in this document is 
given here. 


«?xml version="1.0" encoding-"UTF-8"?» 


«xsd:schema targetNamespace-"urn:ietf:params:xml:ns:iodef-sci-1.0" 
xmlns:xsd-"http://www.w3.org/2001/XMLSchema" 
xmlns:iodef-"urn:ietf:params:xml:ns:iodef-1.0" 
xmlns:sci-"urn:ietf:params:xml:ns:iodef-sci-1.0" 
elementFormDefault-"qualified" attributeFormDefault="unqualified"> 


«xsd:import namespace-"urn:ietf:params:xml:ns:iodef-1.0" schemaLocation- 
"http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/» 


«xsd:complexType name="XMLDATA"> 
<xsd:complexContent> 
<xsd:restriction base="iodef:ExtensionType"> 
<xsd: sequence> 
<xsd:any namespace="##any" processContents-"lax" minOccurs="0" 
maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name="dtype" type="iodef:dtype-type" 
use-"required" fixed-"xml"/» 
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«xsd:attribute name="ext-dtype" type="xsd:string" 
use="prohibited"/> 
<xsd:attribute name="meaning" type-"xsd:string"/» 
<xsd:attribute name="formatid" type="xsd:string"/> 
<xsd:attribute name="restriction" type="iodef:restriction-type"/> 
</xsd:restriction> 
</xsd:complexContent> 
«/xsd:complexType» 
«xsd:complexType name="BasicStructure"> 
<xsd:sequence> 
<xsd:choice> 
<xsd:element name="RawData" type-"sci:XMLDATA" 
minOccurs="0" maxOccurs-"unbounded"/» 
<xsd:element ref-"iodef:Reference" minOccurs="0" 
maxOccurs="unbounded"/> 
</xsd:choice> 
</xsd: sequence> 
<xsd:attribute name="SpecID" type="xsd:string" use="required"/> 
<xsd:attribute name="ext-SpecID" type-"xsd:string"/» 
«xsd:attribute name-"ContentID" type="xsd:string"/> 
«/xsd:complexType» 


«xsd:element name-"Scoring" type-"sci:BasicStructure"/» 
«xsd:element name-"Platform" type-"sci:BasicStructure"/» 
«xsd:element name-"EventReport" type-"sci:BasicStructure"/» 
«xsd:element name-"Verification" type-"sci:BasicStructure"/» 
«xsd:element name-"Remediation" type-"sci:BasicStructure"/» 
<xsd:element name="AttackPattern"> 
<xsd:complexType> 
<xsd:complexContent> 
<xsd:extension base="sci:BasicStructure"> 
<sequence> 
<xsd:element ref="sci:Platform" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 
</xsd:element> 
<xsd:element name="Vulnerability"> 
<xsd:complexType> 
<xsd:complexContent> 
<xsd:extension base="sci:BasicStructure"> 
<sequence> 
<xsd:element ref="sci:Platform" minOccurs="0" 
maxOccurs="unbounded"/> 
<xsd:element ref="sci:Scoring" minOccurs="0" 
maxOccurs="unbounded"/> 
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«/sequence» 
«/xsd:extension» 
</xsd:complexContent> 
</xsd:complexType> 
</xsd:element> 
<xsd:element name="Weakness"> 
<xsd:complexType> 
<xsd:complexContent> 
<xsd:extension base="sci:BasicStructure"> 
<sequence> 
<xsd:element ref="sci:Platform" minOccurs="0" 
maxOccurs="unbounded"/> 
<xsd:element ref="sci:Scoring" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 
</xsd:element> 


</xsd:schema> 
6. Security Considerations 


This document specifies a format for encoding a particular class of 
security incidents appropriate for exchange across organizations. As 
merely a data representation, it does not directly introduce security 
issues. However, it is guaranteed that parties exchanging instances 
of this specification will have certain concerns. For this reason, 
the underlying message format and transport protocol used MUST ensure 
the appropriate degree of confidentiality, integrity, and 
authenticity for the specific environment. Specific security 
considerations are detailed in the messaging and transport documents, 
where the exchange of formatted information is automated; see 
Sections 9 and 10 of "Real-time Inter-network Defense (RID)" 
[RFC6545] and Section 4 of "Transport of Real-time Inter-network 
Defense (RID) Messages over HTTP/TLS" [RFC6546] for a detailed 
overview of security requirements and considerations. 


It is RECOMMENDED that organizations that exchange data using this 
document develop operating procedures that consider, at a minimum, 
the following areas of concern. 

6.1.  Transport-Specific Concerns 
The underlying messaging format, IODEF, provides data markers to 


indicate the sensitivity level of specific classes within the 
structure as well as for the entire XML document. The "restriction" 
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attribute accomplishes this with four attribute values in IODEF 
[RFC5070]. These values are RECOMMENDED for use at the application 
level, prior to transport, to protect data as appropriate. A 
standard mechanism to apply XML encryption using these attribute 
values as triggers is defined in RID [RFC6545], Section 9.1. This 
mechanism may be used whether or not the RID protocol [RFC6545] and 
its associated transport binding [RFC6546] are used in the exchange 
to provide object-level security on the data to prevent possible 
intermediary systems or middleboxes from having access to the data 
being exchanged. In areas where transmission security or secrecy is 
questionable, the application of an XML digital signature [XMLDSIG] 
and/or encryption on each report will counteract both of these 
concerns. The data markers are RECOMMENDED for use by applications 
for managing access controls; however, access controls and management 
of those controls are out of scope for this document. Options such 
as the usage of a standard language (e.g., eXtensible Access Control 
Markup Language [XACML]) for the expression of authorization policies 
can be used to enable source and destination systems to better 
coordinate and align their respective policy expressions. 


Any transport protocol used to exchange instances of IODEF documents 
MUST provide appropriate guarantees of confidentiality, integrity, 
and authenticity. The use of a standardized security protocol is 
encouraged. The RID protocol [RFC6545] and its associated transport 
binding [RFC6546] provide such security with options for mutual 
authentication session encryption and include application-level 
concerns such as policy and workflow. 


The critical security concerns are that structured information may be 
falsified, accessed by unintended entities, or become corrupt during 
transit. We expect that each exchanging organization will determine 
the need, and mechanism, for transport protection. 


6.2. Protection of Sensitive and Private Information 


For a complete review of privacy considerations when transporting 
incident-related information, please see RID [RFC6545], Section 9.5. 
Whether or not the RID protocol is used, the privacy considerations 
are important to consider, as incident information is often sensitive 
and may contain privacy-related information about individuals/ 
organizations or endpoints involved. Organizations will often 
require the establishment of legal reviews and formal policies that 
outline specific details of what information can be exchanged with 
Specific entities. Typically, identifying information is anonymized 
where possible and appropriate. In some cases, information brokers 
are used to further anonymize the source of exchanged information so 
that other entities are unaware of the origin of a detected threat, 
whether or not that threat was realized. 
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It is RECOMMENDED that policies and procedures for the exchange of 
cybersecurity information be established prior to participation in 
data exchanges. Policy and workflow procedures for the exchange of 
cybersecurity information often require executive-level approvals and 
legal reviews to appropriately establish limits on what information 
can be exchanged with specific organizations. RID [RFC6545], 

Section 9.6 outlines options and considerations for application 
developers to consider for policy and workflow design. 


6.3. Application and Server Security 
The cybersecurity information extension is merely a data format. 
Applications and transport protocols that store or exchange IODEF 
documents using information that can be represented through this 
extension will be a target for attacks. It is RECOMMENDED that 
Systems and applications storing or exchanging this information be 
properly secured, have minimal services enabled, and maintain access 
controls and monitoring procedures. 

7. IANA Considerations 
This document uses URNs to describe XML namespaces and XML schemata 
[XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism 


described in [RFC3688]. 


The following IODEF structured cybersecurity information extension 
namespace has been registered: 


URI: urn:ietf:params:xml:ns:iodef-sci-1.0 


Registrant Contact: Refer to the Authors' Addresses section of 
this document. 


XML: None. 


The following IODEF structured cybersecurity information extension 
XML schema has been registered: 


URI: urn:ietf:params:xml:schema:iodef-sci-1.0 


Registrant Contact: Refer to the Authors' Addresses section of 
this document. 


XML: Refer to the XML schema in Section 5.2 of this document. 
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This memo creates the following registry, which is managed by IANA: 


Name of the registry: "Structured Cybersecurity Information (SCI) 
Specifications" 
Name of its parent registry: "Incident Object Description Exchange 


Format (IODEF)" 
URL of the registry: «http://www.iana.org/assignments/iodef» 


Namespace details: A registry entry for a Structured Cybersecurity 
Information Specification (SCI specification) consists of: 


Namespace: A URI [RFC3986] that identifies the XML namespace 
used by the registered SCI specification. In the case where 
the registrant does not request a particular URI, the IANA will 
assign it a Uniform Resource Name (URN) that follows RFC 3553 
[RFC3553]. 


Specification Name: A string containing the spelled-out name of 
the SCI specification in human-readable form. 


Reference URI: A list of one or more of the URIs [RFC3986] from 
which the registered specification can be obtained. The 
registered specification MUST be readily and publicly available 
from that URI. 


Applicable Classes: A list of one or more of the extension 
classes specified in Section 4.5 of this document. The 
registered SCI specification MUST only be used with the 
extension classes in the registry entry. 


Information that must be provided to assign a new value: The above 
list of information. 


Fields to record in the registry: Namespace/Specification Name/ 
Version/Reference URI/Applicable Classes. Note that it is not 
necessary to include a defining reference for all assignments in 


this new registry. 


Initial registry contents: Only one entry, with the following 
values: 


Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2 
Specification Name: Malware Metadata Exchange Format 


Version: 1.2 
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Reference URI: 


«http://standards.ieee.org/develop/indconn/icsg/mmdef.html», 
«http://grouper.ieee.org/groups/malware/malwg/Schemal.2/» 


Applicable Classes: AttackPattern 


Allocation policy: Specification Required (which includes Expert 
Review) [RFC5226]. 


The Designated Expert is expected to consult with the MILE (Managed 
Incident Lightweight Exchange) working group, or its successor if any 
such working group exists (e.g., via email to the working group's 
mailing list). The Designated Expert is expected to retrieve the SCI 
specification from the provided URI in order to check the public 
availability of the specification and verify the correctness of the 
URI. An important responsibility of the Designated Expert is to 
ensure that the registered applicable classes are appropriate for the 
registered SCI specification. 
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